1. Field of the Invention
The present invention relates to a debug aid device for testing an execution code sequence and fixing bugs and to a program compiler device for generating the execution code sequence to be processed by the debug aid device.
2. Description of the Prior Art
Microcomputer systems are essential for electronic equipment today. Especially, programs developed for use in household electrical appliances have to achieve the level of quality required for mass production and thus need to be throughly debugged. Hence debug aid devices have become profoundly important when developing programs.
The debug aid devices are mainly classified into three types. The first type operates a debug target program in a target machine ROM. The second type operates the debug target program on an ICE (In-Circuit Emulator) board (trademark). The third type operates the debug target program in simulation using a simulator in a host computer.
These debug aid devices each run and stop the debug target program stored in the target machine at given addresses. Programmers can see the process of correcting values of the of memory and registers on the host computer display. Also, by temporarily changing parameters in the debug target program before running it, the programmers can examine the operation of the debug target program in various circumstances. By using the debug aid devices as described above, the programmers can find and diagnose bugs in the debug target program.
To debug variables or subroutines stored in the debug target program, a programmer specifies execution codes expressed by hexadecimal values as the debug target since the variables and the subroutines are written in execution codes in the debug target program. Accordingly, the debug aid devices should be able to restore mnemonic codes which resembles source codes from the specified hexadecimal values (hereinafter, binary data) in order to simplify the debugging.
A debug aid device with the above restoring capacity can convert specified execution codes in the target machine memory to mnemonic codes that can easily be understood by the programmer. Also, the programmer can specify the start and stop addresses of the debug target program by subroutine names written in the source program, and not actual addresses in the target machine memory. Equally, the programmer can specify program variables to be debugged by variable names written in the source program, and not actual addresses in the target machine memory.
However, with the conventional debug aid devices, it is difficult to debug an execution code that corresponds to a section of a source program that includes a long-word constant, since statements including a long-word constant in the source program correspond to a plurality of execution codes in the debug target program.
More specifically, when the source program includes a statement with a long-word constant, a program compiler device does not compile the statement to create an execution code that includes the long-word constant. Instead, the long-word constant in the statement is first divided into a plurality of subconstants and the statement is compiled to a plurality of execution codes which use the plurality of subconstants as operands.
When converting the plurality of execution codes generated as such to a plurality of mnemonic codes in the debug stage, the programmer may be confused on finding a plurality of strange operands in the mnemonic codes, instead of the long-word constant which was originally written in the source program.
Also, when the programmer tries to identify the original long-word constant from execution codes which include a plurality of subconstants generated from the long-word constant, the programmer may confuse these subconstants with other subconstants generated from a different long-word constant.
Also, when temporarily changing a long-word constant in the debug target program, the programmer needs to control the target machine to read a plurality of execution codes that include the plurality of subconstants from the memory so as to identify the long-word constant to be changed. This requires a considerable amount of processing time. The programmer also needs to know at which bit position the original long-word constant has been divided. Because of these difficulties, the programmer often gives up changing long-word constants in the debug stage.
In debug processing, the instruction length in the debug target program is fixed so that the processor executes instructions at high speed. For example, processors equipped in SPARC (Scalable Processor ARChitecture) work stations developed by Sun Microsystems Inc. use the 32-bit fixed instruction length. Each 32-bit constant included in source programs developed for use in these processors is first divided into two subconstants of the high-order bits and the low-order bits and then compiled to two execution codes.
FIG. 1 shows a result of executing a reconversion command on four execution codes written in addresses 0.times.80000000 to 0.times.8000000F using a SPARC processor. In the figure, the four execution codes express an instruction for assigning a constant "0.times.12345A32" to variable a stored in address 0.times.00001000. As shown in the figure, a debug command is inputted for displaying a list from "sethi %hi(0.times.12345800),%o0" to "st %o0,[%o1+0.times.000]". The columns from left to right show line numbers corresponding to the source program, execution code addresses, execution codes in machine language, and mnemonic codes as the reconversion results.
The mnemonic code "sethi %hi(0.times.12345800),%o0" shows an instruction for storing high-order 22 bits of the constant "0.times.12345A32" into register %o0. The mnemonic code "or %o0,232,%o0" shows an instruction for performing an OR operation on the value of register %o0 and a constant operand "232" and storing the operation result into register %o0. The mnemonic code "sethi %hi(0.times.00001000),%ol" shows an instruction for storing a constant "0.times.00001000" into register %o1. The mnemonic code "st %o0,[%o1+0.times.000]" shows an instruction for storing the value of register %o0 into an address specified by the value of register %o1 and a constant operand "0.times.000".
Among the above instructions, "sethi %hi(0.times.12345800),%o0" and "or %o0,232,%o0" respectively include a 22-bit subconstant "0.times.12345800" and a 10-bit subconstant "0.times.232". This indicates that the 32-bit constant "0.times.12345A32" originally written in the source program has been divided into the two subconstants and then loaded into the target machine memory, since it matches the fixed instruction length specified for the processor. In the same way, "sethi %hi(0.times.00001000),%o1" and "st %o0,[%o1+0.times.000]" show that address 0.times.00001000 of variable a has been divided into the two subconstants before being loaded into the memory.
If the programmer knows that each 32-bit constant in the source program has been divided into the high-order 22 bits and the low-order 10 bits, it is not impossible to detect the original constant corresponding to the mnemonic code "sethi %hi(0.times.12345800),%o0" and "or %o0,232,%o0". However, when 32-bit constants are divided according to a plurality of division patterns, such as "4, 4, 4, 20" and "8, 24", it is more difficult and time-consuming to detect the original constant.